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Abstract 


Defence  Research  and  Development  Canada  (DRDQ  has  been  developing  a  low  cost  means  to 
evaluate  the  integration  of  new  display  equipment  for  the  Air  Force.  The  result  has  been  the 
Aircraft  Crewstation  Demonstrator  (ACD),  which  is  capable  of  simulating  the  cockpit  of  an 
aircraft  for  human  factors  evaluation  (HFE).  In  order  to  support  future  display  upgrades  within 
the  cockpit  of  the  CF-18,  DRDC  contracted  an  FIFE  study  ofthe  CF-18  displays,  especially  the 
radar  displays  associated  with  radar  and  data  link.  Earlier  work  at  the  Defence  Research 
Establishment  Ottawa  (DREO)  had  resulted  in  a  high  fidelity  simulation  of  the  air  to  air  modes  of 
a  fighter  radar.  In  order  to  develop  as  representative  display  as  possible,  a  task  to  integrate  the 
ACD  with  the  DREO  radar  simulation  as  a  distributed  simulation  was  included  with  the  HFE 
study.  This  report  describes  the  use  of  the  high  level  architecture  (HLA)  to  combine  these  two 
disparate  simulations  into  one  distributed  simulation.  The  results  indicate  that  HLA  is  an 
effective  means  of  combining  different  models  to  provide  an  improved  simulation  to  the  user. 
Advantages  and  limitations  are  discussed,  as  is  a  proposed  future  architecture. 


Resume 


Recherche  et  Developpement  pour  la  Defense  Canada  (RDDC)  ont  developpe  une  fa^on  peu 
couteuse  d'evaluer  l'integration  d'ecrans  de  presentation  pour  les  Forces  Aeriennes  du  Canada.  II 
en  a  resulte  un  simulateur  de  poste  de  pilotage  d'avion  pour  devaluation  de  facteurs  humains  qui  a 
pour  nom  le  Aircraft  Crewstation  Demonstrator  (ACD).  Dans  le  but  de  supporte  l'ajout  de 
nouveaux  ecrans  radars  pour  le  CF-18,  RDDC  a  contract^  une  etude  portant  sur  devaluation  des 
facteurs  humains  en  focalisant  principalement  sur  les  ecrans  affichant  l'information  provenant  du 
radar  et  du  Data  Link.  Des  travaux  precedents  conduit  au  Centre  de  Recherches  pour  la  Defence, 
Ottawa  (CRDO)  ont  resulte  en  un  simulateur  fidele  des  modes  air-air  d'un  radar  d'avion  de 
chasse.  Dans  le  but  de  developper  une  presentation  des  plus  realistes,  l'integration  de  l'ACD  et  du 
simulateur  radar  de  CRDO  a  aussi  ete  incluse  dans  l'etude  portant  sur  devaluation  des  facteurs 
humains.  L'utilisation  de  l'architecture  de  haut  niveau  (HLA)  dans  le  but  de  combiner  les  deux 
types  de  simulations  en  une  seule  simulation  distribute  est  discutee  dans  ce  rapport.  Les  resultats 
demontrent  que  l'architecture  HLA  est  un  moyen  efficace  de  combiner  differents  types  de 
modeles  afin  d'ameliorer  une  simulation  par  rapport  a  l'utilisateur.  Les  avantages  et  restrictions  y 
sont  discutes  en  plus  d'y  proposer  une  nouvelle  architecture  pour  des  utilisations  futures. 
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Executive  Summary 


Defence  Research  and  Development  Canada  has  been  developing  various  capabilities  to  support 
the  modernization  of  the  CF-1 8.  DREO  has  developed  a  high  fidelity  radar  simulator,  SAFIRE, 
for  the  CF-1 8,  while  DCIEM  has  been  responsible  for  the  development  of  the  air  crewstation 
demonstrator  (ACD)  that  is  capable  of  simulating  the  cockpit  of  an  aircraft  to  facilitate  human 
factor  studies  for  the  CF-18.  This  project  summarizes  the  merging  ofthese  two  capabilities  into 
a  single  distributed  simulation  using  the  high  level  architecture  (HLA)  developed  by  the  US 
Defense  Modelling  and  Simulation  Organization. 

The  development  of  the  distributed  simulation  was  one  of  the  tasks  of  a  human  factors  evaluation 
of  prototype  displays  for  the  CF-18  aircraft.  These  prototype  displays  were  to  demonstrate  the 
inclusion  of  new  capabilities  to  the  cockpit  in  order  to  improve  operator  effectiveness.  The 
purpose  of  the  distributed  simulation  task  was  to  provide  a  validated  radar  model  to  a  human-in- 
the-loop  simulation  while  demonstrating  the  ability  of  such  a  legacy  simulation  to  be  integrated 
into  a  larger  system.  The  various  hardware  and  software  components  of  the  cockpit  simulation 
and  radar  model  are  described.  The  design  of  the  simulation  interfaces  of  these  components  was 
accomplished  using  the  HLA  methodology  and  consisted  of  the  creation  of  a  federation  object 
model  to  describe  all  of  the  interactions.  The  implementation  of  the  federation  is  discussed  along 
with  a  summary  of  the  difficulties  encountered  during  the  implementation  and  integration  phases. 
This  includes  some  of  the  compromises  that  had  to  be  used  to  achieve  system  operation  in  the 
time  provided  for  the  project. 

Overall,  the  demonstration  of  the  distributed  simulation  was  successful.  The  SAFIRE  radar 
model  was  used  in  26  of  the  32  test  scenarios,  and  the  resulting  performance  of  the  total 
simulation  was  praised  by  the  operators.  This  task  demonstrated  that  the  effort  to  include  a  high 
fidelity  legacy  sensor  model  into  a  distributed  simulation  is  relatively  minor  when  the  sensor 
model  is  designed  in  a  modular  fashion  and  the  HLA  runtime  infrastructure  is  used.  It  also 
demonstrated  that  some  high  fidelity  models  should  be  avoided  due  to  the  runtime  limitations 
typical  of  these  systems.  Future  work  with  human-in-the-loop  simulations  are  recommended  to 
use  simpler  representative  sensor  models.  The  results  have  also  demonstrated  that  it  should  be 
possible  to  create  a  complete  missile  engagement  simulation  using  a  federation  consisting  of 
current  aircraft,  radar,  electronic  support  measures,  electronic  counter  measures,  missile  seeker 
and  missile  models. 


Geling,  G.;  Williams,  C.;  Guirguis,  M.  2001.  D-SAFIRE:  A  Distributed  Simulation.  DREO  TM 
2001-151.  Defence  Research  Establishment  Ottawa. 
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Sommaire 


Dans  lc  but  dc  supporter  la  modernisation  du  CF-18,  differentes  capacitcs  ont  etc  dcvcloppcs  par 
Recherche  et  Developpement  pour  la  Defense  Canada  (RDDC).  Un  simulatcur  radar  dc  haute 
fiabilitc,  SAFIRE,  a  etc  con^uc  au  CRDO  alors  que  IMED  etait  plutot  rcsponsablc  du 
developpent  du  simulatcur  Aircraft  Crewstation  Demonstrator  (ACD)  modclisant  un  postc  dc 
pilotage  d'avion  dans  lc  but  dc  facilitcr  l'ctudc  dcs  factcurs  humains  dans  lc  CF-18.  Cc  projet 
resume  la  fusion  dc  ccs  deux  technologies  cn  unc  seulc  simulation  distribute  utilisant 
l'architccturc  de  haut  niveau  (HLA)  con^uc  l'Organisation  dc  la  Modclisatbn  et  Simulation  dc  la 
Defense  des  Etats-Unis. 

Le  developpement  dc  cettc  simulation  distribute  est  unc  des  tachcs  faisant  partic  dc  Evaluation 
d'tcrans  dc  prtsentation  prototypt  pour  le  CF-1 8.  Ces  tcrans  dc  prtsentations  proto typts  ont  pour 
but  dc  dtmontrer  l'inclusion  dc  nouvclles  capacitts  au  poste  de  pilotage  afin  d’amtliorcr 
l'efficacitt  dc  l'optratcur.  L'objcctif  de  la  tachc  baste  sur  la  simulation  distribute  est  d'introduirc 
un  modele  radar  validc  a  unc  simulation  dc  types  "  humains  dans  la  bouclc  "  tout  en  dtmontrant 
les  possibilitts  d'inclure  une  simulation  plus  agtc  dans  un  systeme  dc  large  envergure.  Les 
diverscs  composantes  logicicls  et  mattriels  du  simulatcur  dc  postc  dc  pilotage  ainsi  que  du 
modele  radar  y  sont  ici  prtsentts.  Les  interlaces  dc  simulations  associtcs  a  ccs  composantes  ont 
ttt  con<;ucs  cn  se  basant  sur  la  mtthodologic  HLA  cc  qui  a  consistts  a  la  creation  d'unc 
ftdtration  de  modclcs  dtcrivanttoutes  les  interactions  entre  les  objets.  L'implantation  dc  la 
ftdtration  d'objets  y  est  discuttc,  de  plus,  unc  description  sommaire  dcs  problcmcs  rencontres 
dans  la  phase  d'implantation  et  d'inttgration  y  est  prtscnttc.  Cc  dernier  point  inclut  les 
compromis  utilists  afin  d'obtcnir  un  systeme  optrationnel  a  l'inttricur  du  temps  allout  a  cc 
projet. 

Dans  l'ensemble,  les  dtmonstrations  dc  simulations  distributes  ont  ttt  accomplics  avee  succcs. 

Le  modele  radar  SAFIRE  a  ttt  utilist  dans  26  dcs  32  setnarios  dc  test  et  les  performances 
rtsultantes  dc  la  simulation  globale  ont  ttt  fortement  apprtcitcs  par  les  optratcurs.  Cette  tachc  a 
dtmontrt  que  l'effort  ntcessaire  afin  d'inclure  un  modele  dc  captcur  plus  agt  dans  unc 
simulation  distribute  est  relativement  minime  lorsquc  que  lc  modele  dc  captcur  est  congu  dans 
unc  approchc  modulairc  et  que  l'infrastructure  HLA  est  utilistc.  Ellc  a  aussi  dtmontrt  que 
l'utilisation  dc  modclcs  dc  captcurs  dc  tres  grandcs  fidtlitts  doit  etre  proscritc  ttant  donnt  leurs 
limitations  en  temps  d'exteution.  L'utilisation  dc  modele  dc  captcurs  simplifits  est  rccommandtc 
pour  de  futures  simulations  dc  types  "  humains  dans  la  bouclc  ".  Les  rtsultats  ont  aussi  dtmontrt 
qu'il  devrait  etre  possible  dc  erter  unc  simulation  complete  d'un  engagement  dc  missile  utilisant 
sur  une  ftdtration  comprcnant  l'avion  actucl,  lc  radar,  les  mesures  dc  soutient  tlcctroniquc,  les 
contrc-mcsures  tlectroniqucs  ainsi  que  des  modclcs  dc  missiles  et  dc  missiles  chcrcheuts. 

Geling,  G.;  Williams,  C.;  Guirguis,  M.  2001.  D-SAFIRE:  A  Distributed  Simulation.  DREO  TM 
2001-151.  Centre  dc  Recherchcs  pour  la  Dtfense  Ottawa. 
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1.  Project  Overview 

1.1  Introduction 

The  Department  of  National  Defence  has  been  considering  the  upgrade  of  the  avionics  of  the  CF- 
18  fighter  aircraft.  Two  main  areas  of  improvement  in  the  aircraft  will  be  the  upgrade  of  the 
APG-65  radar  to  the  APG-73  radar  and  the  inclusion  of  an  improved  data  link  capable  of 
downloading  target  information  to  the  CF-18  from  external  sources.  Defence  Research  and 
Development  Canada  (DRDC)  has  been  developing  a  low  cost  means  to  evaluate  the  integration 
of  new  display  equipment  for  the  Air  Force.  The  result  has  been  the  Aircraft  Crewstation 
Demonstrator  (ACD),  which  is  capable  of  simulating  the  cockpit  of  an  aircraft  for  human  factors 
evaluation  (HFE).  This  capability  was  initially  developed  to  evaluate  a  missile  approach  warning 
system  interface  (MAWS)  for  the  CH-146  helicopter  [1],  In  that  project,  the  ACD  was  integrated 
with  missile  simulation  and  detection  equipment  to  provide  realistic  sensor  performance  to  the 
operators.  The  technology  developed  in  the  MAWS  program  is  transferable  to  other  aircraft, 
such  as  the  CF-18.  To  support  the  expected  display  upgrades  in  the  cockpit  of  the  CF-18,  DRDC 
contracted  an  HFE  study[2]  to  develop  and  evaluate  an  upgraded  air  crew  interface  for  the  radar. 

One  of  the  objectives  of  the  HFE  study  was  to  establish  a  functioning  rapid  prototype  capable  of 
interacting  with  existing  third-party  radar  models.  Earlier  work  at  the  Defence  Research 
Establishment  Ottawa  (DREO)  had  resulted  in  a  high  fidelity  simulation  of  the  air-to-air  modes 
of  a  fighter  radar  [3] .  The  DREO  Simulator  for  advanced  fighter  radar  EPM  (SAFIRE)  had 
originally  been  developed  to  display  the  interaction  between  the  operator  and  the  radar  in  an  EW 
environment  in  as  realistic  and  timely  a  manner  as  possible.  In  order  to  develop  as  representative 
a  display  as  possible,  a  task  to  integrate  the  ACD  with  the  DREO  radar  simulation  as  a 
distributed  simulation  was  included  with  the  HFE  study.  The  work  on  this  contract  was  to  take 
advantage  of  the  experience  gained  with  the  MAWS  simulation.  The  ACD  and  the  radar  model 
would  be  implemented  at  separate  facilities  and  interact  via  the  DMSO  high  level  architecture 
(HLA).  The  resulting  distributed  simulation  would  provide  the  cockpit  experience  at  the 
contractor’s  facility  while  the  detailed  radar  models  would  run  at  DREO. 

This  report  describes  the  development  of  the  various  simulation  components  and  the  use  of  HLA 
to  combine  these  two  disparate  simulations  into  one  distributed  simulation.  The  remainder  of 
this  chapter  describes  the  initial  hardware  and  software  configurations  that  the  simulation  was 
built  on.  Chapter  2  discusses  the  various  analysis  carried  out  and  the  resulting  design  decisions. 
Chapter  3  summarizes  the  implementation  and  integration  phase  and  Chapter  4  presents  the 
results  and  conclusions.  In  general,  the  results  indicate  that  HLA  is  an  effective  means  of 
combining  different  models  to  provide  an  improved  simulation  to  the  user  but  that  such 
simulations  require  detailed  expertise  when  creating  the  user  interface. 
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1.2  Software  Architecture 


The  distributed  simulation  can  be  divided  into  three  major  software  components.  These 
components  consist  of  the  Aircraft  Crcwstation  Demonstrator  (ACD),  the  distributed  version  of 
the  “SAFIRE  APG-65  Radar”,  and  the  Run  Time  Infrastructure  (RTI).  A  diagram  of  the 
distributed  software  objects  and  communication  between  the  objects  can  be  seen  in  Figure  1. 

The  Air  Crcwstation  Demonstrator  consists  of  two  components.  The  “CF-188  ACD”  and  the 
“ACD  Simulation  Environment”.  The  “CF-1 88  ACD”  simulates  the  environment  of  the  cockpit 
and  the  flight  dynamics  of  the  aircraft  simulated  for  the  pilot.  The  software  component  consists 
three  components,  the  graphical  display  environment,  a  mission  computer  simulation  and  a  flight 
simulator.  The  flight  simulator  is  a  commercial  off-the-shelf  (COTS)  product,  FLSIM,  and 
provides  a  real  time,  high-fidelity  simulation  of  the  flight  characteristics  and  handling  of  any 
fixed  wing  aircraft  (The  CF-1 8  in  this  case).  It  translates  the  inputs  received  from  the  user 
interface  into  changes  in  the  flight  profile  of  the  CF-1 8.  The  mission  computer  simulation  is 
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Figure  1  Distributed  simulation  software  architecture 
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used  to  control  the  interface  between  the  flight  simulation  and  the  radar  simulation  and  display. 
The  internal  displays  and  controls  of  the  CF-18  are  generated  and  interfaced  to  the  flight 
simulation  through  the  use  of  the  COTS  tool,  VAPS.  This  tool  is  designed  to  assist  the 
developers  in  quickly  creating  new  prototype  displays.  The  other  component  of  the  ACD  is  the 
“ACD  Simulation  Environment”.  This  component  controls  the  simulated  environment  outside  of 
the  aircraft  being  simulated  for  the  pilot.  This  environment  is  maintained  by  another  COTS 
software  tool,  STAGE.  STAGE  (Scenario  Toolkit  And  Generation  Environment)  is  used  to  build 
and  animate,  in  real-time,  a  synthetic  environment  that  may  contain  both  moving  and  stationary 
entities  such  as  airplanes,  ships,  land  vehicles,  missiles,  and  radar  sites.  The  simulated  external 
environment  is  created  by  the  VEGA  program.  VEGA  generates  the  visual  scenes  for 
presentation  to  the  pilot  on  three  projection  screens.  These  entities  interact  with  one  another 
either  as  a  function  of  pre-determined  rule  sets  or  through  operator  intervention  during  execution 
of  the  simulation.  This  provides  a  development  framework  for  aerospace  and  defence  simulation 
and  training  applications.  The  targets  in  the  tactical  scenarios  are  all  configured  to  act  via  the  rule 
sets,  and  the  operator  interaction  is  provided  for  the  piloted  CF-18  via  integration  with  FLSM. 

The  “SAFIRE  APG-65  Radar”  component  is  a  high  fidelity  radar  simulation.  SAFIRE  was 
developed  by  the  Aerospace  Radar  and  Navigation  section  of  DREO  to  simulate  air-to-air  modes 
of  the  radar  for  the  CF-18  in  electronic  warfare  environments.  SAFIRE  generates  the  radar 
returns  for  all  simulated  targets,  electronic  counter-measures,  and  generic  ground  clutter  and 
processes  them  using  algorithms  similar  to  those  used  in  the  APG-65.  The  air-to-air  modes 
implemented  in  the  current  version  of  SAFIRE  include  the  Range-While-Search  (RWS)  modes, 
the  Track- While-Scan  (TWS)  modes  and  the  monopulse  single  target  track  (STT)  modes.  The 
results  of  the  radar  processing  are  then  presented  on  a  display  in  the  format  that  the  operators  are 
familiar  with  as  shown  in  Figure  2.  The  SAFIRE  simulation,  while  very  complex,  was  still 
capable  of  running  un-altered  for  one  target  at  approximately  five  times  real  time.  For  example, 
the  SAFIRE  requires  five  seconds  to  run  through  one  second  of  simulated  time.  Additional 
targets  or  jamming  techniques  reduce  the  run  time  performance.  The  project  plan  was  to  create  a 
modified  version  of  the  SAFIRE  program,  D-SAFIRE,  to  run  in  real-time  as  part  of  a  distributed 
simulation. 

All  of  the  information  between  the  radar  simulation  and  the  cockpit  simulation  are  regulated  by 
the  HLA  communications  protocols.  The  HLA  is  a  framework  developed  by  the  United  States 
Department  of  Defence,  Defence  Modelling  and  Simulation  Office  (DMSO)  that  supports 
distributed  simulations  by  defining  an  interface  between  the  distributed  components.  The  HLA 
interface  specification  defines  a  Run  Time  Infrastructure  (RT1)  which  is  the  component  of  the 
distributed  simulation  that  provides  the  implementation  and  encapsulation  of  the  communication 
protocols  defined  in  the  HLA  specification.  The  RTI  implementation  handles  the  communication 
between  the  simulation  components  while  hiding  the  details  of  the  how  the  communication  is 
achieved.  HLA  describes  a  distributed  simulation  as  a  federation  and  all  of  the  simulation 
participants  as  federates.  HLA  RTI  1.3  has  received  status  as  an  IEEE  standard  (IEEE  1516, 
1516.1, 1516.2)  and  the  interface  specification  is  described  in  [4] . 
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Figure  2:  SAFIRE  Graphical  User  Interface. 


The  HLA  components  that  come  from  DMSO  arc  the  RTIcxccutive  and  fedex  programs.  These 
programs  arc  essential  to  operation  of  the  distributed  simulation.  The  RTIcxccutive  program  is 
contacted  by  all  simulation  components  when  they  join  the  simulation.  When  a  simulation 
federation  is  started  the  RTIcxccutive  starts  a  fedex  process  to  manage  the  federation.  When  a 
simulation  federate  joins  a  federation  a  connection  is  established  between  that  federate  and  all 
other  federates  in  the  simulation.  Establishing  and  managing  the  connections  is  accomplished  by 
the  RTI  objects  that  come  as  part  of  the  HLA  implementation  from  DMSO. 
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1.3  Hardware  Architecture 


The  network  configuration  of  the  hardware  used  for  the  distributed  simulation  is  illustrated  in 
Figure  3.  The  D-SAFIRE  and  ACD  components  were  located  at  physically  separate  sites.  As  in 
the  MAWS  trial,  ISDN  protocols  were  used  to  connect  the  two  sites.  The  two  ISDN  routers  were 
the  only  points  of  communication  between  the  machines  at  the  CMC  and  DREO  sites 

D-SAFIRE  was  implemented  on  Schroeder,  a  SUN  workstation  with  the  Solaris  2.7  operating 
system.  Schroeder  was  located  at  DREO.  During  the  simulation  Schroeder  was  connected  via  a 
10  Base-T  line  to  a  router  at  DREO,  which  communicated  with  the  router  at  CMC.  During  the 
simulations  Schroeder  was  removed  from  the  Local  Area  Network  (LAN)  at  DREO.  This 
ensured  the  security  of  the  DREO  LAN  and  guaranteed  that  Schroeder  would  be  dedicated  to 
running  the  D-SAFIRE  program. 

The  DREO  router  communicated  with  a  router  at  CMC  using  a  dedicated  ISDN  line.  The 
dedicated  ISDN  line  between  CMC  and  DREO  was  used  to  eliminate  possible  problems  with 
network  congestion  during  the  simulation.  The  dedicated  line  also  provided  a  means  to  connect 
the  systems  at  CMC  and  DREO  without  dealing  with  the  corporate  firewalls  while  maintaining 
security  for  the  simulation.  The  ISDN  line  provided  2  channels,  each  with  a  bandwidth  of 
64Kbps.  The  connection  between  the  CMC  router  and  the  ACD  used  a  10  Base-T  line.  The 
details  of  the  network  configuration  can  be  seen  in  Annex  A. 

The  ACD  components  were  located  at  CMC  Electronics  in  their  Human  Factors  Engineering 
(HFE)  lab.  The  ACD  environment  consisted  of,  three  SGI  workstations  and  an  Intel  PC.  The 
Intel  PC  was  used  to  generate  the  sound  effects  for  the  simulation.  The  SGI  workstations  are 
labelled  Onyx  1  &  2  and  Octane.  Communication  between  workstations  at  CMC  was  done  using 
User  Datagram  Protocol  (UDP)  connections  over  a  local  area  network  in  the  HFE  lab.  A 
photograph  of  the  ACD  cockpit  is  given  in  Figure  4. 
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Figure  3:  Distributed  Simulation  Hardware  Configuration 


Figure  4:  ACD  Cockpit 
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2.  Simulation  Analysis  and  Design 

This  section  presents  the  design  done  for  the  distributed  simulation.  As  part  of  the  HLA  design 
method  a  Federation  Object  Model  (FOM)  for  the  simulation  was  developed.  The  development 
of  the  FOM  is  summarized  in  section  2.1 .  Following  the  summary  of  the  FOM,  a  discussion  of 
the  issues  involved  in  integrating  the  HLA  interface  with  S  AFIRE  and  the  ACD  is  presented  in 
sections  2.2  and  2.3. 

2.1  Generation  of  the  Federation  Object  Model 

In  accordance  with  the  HLA  specifications,  the  federation  must  be  described  by  a  FOM.  The 
FOM  defines  who  will  be  in  the  simulation,  what  information  will  be  exchanged  and  how  the 
information  is  represented.  This  task  was  completed  by  VPI  and  documented  in  theD-SAFIRE 
Federated  Object  Model  report  [5].  The  specification  of  the  FOM  was  based  on  what 
information  S AFIRE  would  need  to  perform  it’s  core  function  (i.e  simulate  the  radar  for  the  CF- 
18  (APG-65))  and  what  would  be  needed  by  the  ACD  to  integrate  the  results  with  the  cockpit 
displays.  During  the  development  phase  CMC  was  consulted  and  their  input  was  integrated  with 
the  FOM.  The  FOM  was  submitted  to  DREO  and  CMC  for  review  and  approval  before  any 
detailed  design  and  implementation  work  began. 

The  FOM  for  this  simulation  consists  of  five  control  interactions  and  four  data  passing 
interactions  between  the  ownship  aircraft  and  radar  sensor  objects.  These  are  listed  in  Table  1 
with  the  indication  for  each  object  of  which  signals  can  be  initiated  and  which  must  respond. 

The  control  signals  consist  of  two  signals  to  start  and  stop  the  radar  simulation  (Create  Radar 
Object,  Destroy  Radar  Object),  two  signals  to  control  the  processing  of  current  flight  dynamics 
by  the  radar  simulation  (Radar  Pause  Request,  Radar  Continue  Request)  and  a  final  signal  to 
indicate  the  end  of  the  simulation.  The  four  data  interactions  convey  the  latest  target  information 
(Update  Target  Processing  list),  ACD  information  (Update  Aircraft),  the  Radar  Parameters  to 
use  in  the  simulation  and  the  radar  detections  (Radar  Status  Report). 

The  Update  Target  Processing  List  consisted  of  the  range,  radial  velocity  and  acceleration, 
azimuth  and  elevation  relative  to  the  ACD  for  each  target  in  the  list.  In  addition  to  the  flight 
dynamics  of  the  target  aircraft,  the  radar  cross  section  and  radar  cross  section  model  to  be  used  in 
the  simulation  were  also  sent  for  each  target.  A  flag  to  indicate  the  use  of  a  jammer  by  a  target 
aircraft  was  also  included  as  part  of  the  target  update. 

The  Update  Aircraft  interactions  contained  a  Time  Space  Position  Indicator  (TSP1)  for  the  ACD 
as  well  as  the  weapon  configuration.  The  TSPI  contained  the  latitude,  longitude  and  altitude  of 
the  ACD  as  well  as  the  velocity  and  acceleration  in  (North,  East  and  Down  coordinates). 
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Interaction  Classes 

Ownship  Aircraft 

Radar  Sensor 

Description 

Terminate  Simulation 

I 

R 

Signals  D-SAFIRL  to  halt  operation 
completely  and  shut  down 

Create  Radar  Object 

IR 

IR 

Start  and  initialize  D-SAFIRL 

Destroy  Radar  Object 

IR 

IR 

Terminate  Ihe  current  D-SAFIRL  session 

Radar  Pause  Request 

IR 

IR 

Pause  required  for  debugging  purposes 

Radar  Continue  Request 

IR 

IR 

Continue  required  for  debugging 
purposes 

Update  Aircraft 

I 

R 

Motion  model  updates  for  ownship 
aircraft 

Update  Target  Processing 

List 

I 

R 

Motion  model  updates  for  target  aircraft 

Radar  Parameters 

IR 

IR 

Requests  changes  in  the  radar 
configuration,  ie.  Mode  change 

Radar  Status  Report 

R 

I 

Results  of  last  radar  processing  interval. 

Table  1:  Interaction  Classes  used  to  implement  the  radar  federation. 


The  Radar  Parameter  interaction  is  used  to  communicate  the  operating  conditions  of  the  radar 
between  the  ACD  radar  and  D-SAFIRE.  This  interaction  contains  the  radar  azimuth  and 
elevation  centre,  the  azimuth  scan  range,  the  current  operating  mode  and  the  current  azimuth  and 
elevation  of  the  radar  antenna.  The  definition  of  the  FOM  was  defined  assuming  that  only  the 
search  modes  would  initially  be  implemented.  There  were  additional  fields  defined  in  the 
interaction  to  support  acquisition  and  tracking  modes.  These  fields  were  not  used  in  this 
simulation  and  arc  not  detailed  here.  More  detailed  information  about  can  be  found  in  the  D- 
S AFIRE  Federation  Object  Model  report. 

The  Radar  Status  Report  generated  by  SAFIRE  is  used  to  communicate  to  the  ACD  the  location 
of  any  detections  from  the  most  recent  processing  interval.  The  status  report  contains  the  range, 
closing  velocity,  azimuth  and  elevation  of  the  detection.  The  status  report  also  contains  a  values 
to  indicate  what  kind  of  detection  was  made,  the  quality  of  the  detection  and  an  estimate  of  the 
target  that  generated  the  detection. 


From  the  FOM  a  federation  execution  details  (fed)  file  is  generated.  This  is  a  text  file  that  defines 
at  a  high  level  what  can  be  exchanged  between  federates  in  the  simulation.  This  file  is  used  at  run 
time  by  the  RTI objects  when  communicating  between  federates.  The  file  used  for  the  SAFIRE 
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simulation  has  been  included  as  Annex  B.  The  federation  execution  details  file  was  generated  by 
the  Object  Model  Development  Tool  (OMDT)  provided  by  DMSO. 

Once  the  FOM  was  specified,  the  design  of  the  ACD  and  D-SAFIRE  modules  began.  The  details 
of  integrating  the  HLA  module  with  S AFIRE  are  in  the  next  section.  Section  2.3  discusses  the 
integration  of  the  HLA  module  with  the  ACD. 

2.2  HLA  Integration  with  SAFIRE 

The  integration  of  the  radar  model  with  a  human-in-the-loop  distributed  simulation  required  a 
number  of  modifications  to  the  original  SAFIRE  program.  One  important  requirement  was  the 
ability  of  the  radar  model  to  respond  in  realtime.  The  other  was  to  ensure  that  the  modified 
SAFIRE  program  interacted  properly  with  the  ACD  federation.  A  detailed  software  design 
document  [6]  was  developed  for  modifying  the  existing  SAFIRE  program  to  participate  in  the 
distributed  simulation.  The  resulting  modified  program  is  referred  to  as  D-SAFIRE. 

Throughout  the  implementation  phase,  the  software  design  document  was  synchronized  with  the 
actual  implementation. 

At  the  start  of  this  project,  the  SAFIRE  program  ran  from  three  times  to  one  hundred  times 
slower  than  real-time,  depending  on  simulation  options.  Prior  to  modifying  SAFIRE  to  add  HLA 
components,  software  optimizations  were  done  to  SAFIRE  and  hardware  upgrades  were  applied 
to  the  Schroeder  workstation.  The  details  and  results  of  the  upgrades  are  documented  in  the 
SAFIRE  Performance  Enhancements  Technical  Note,  Update  [3].  The  optimizations  allowed  the 
Scientific  Simulation  Software  in  SAFIRE  to  operate  in  realtime  while  simulating  up  to  four 
targets.  Several  components  of  the  simulation  had  to  be  selected  off.  The  most  intensive 
component  of  the  simulation,  the  calculation  of  radar  returns  from  the  surface  of  the  earth,  had  to 
be  turned  off  for  the  realtime  simulation.  Once  the  optimizations  and  upgrades  were  done,  work 
began  on  the  implementation  of  modifications  to  SAFIRE  required  to  support  the  HLA 
components. 

The  existing  SAFIRE  program  consisted  of  two  major  components,  the  Scientific  Simulation 
Software  (SSS),  and  the  graphical  user  interface  (GUI).  The  RTI  communications  for  the 
simulation  were  created  as  a  separate  component  that  was  placed  between  the  current  GUI  and 
SSS  components.  This  required  only  minimal  changes  to  the  GUI  portion  of  the  simulation.  The 
resulting  radar  model  is  shown  in  Figure  5.  In  order  to  allow  the  possibility  of  multiple  restarts 
of  the  radar  model  during  the  simulation,  a  parent  SAFIRE  federate  was  used  to  start  and  stop  the 
D-SAFIRE  radar  model.  The  implementation  began  by  the  adding  the  control  signals  in  the 
FOM  to  SAFIRE.  The  control  signals  could  be  easily  tested  and  verified.  The  implementation 
proceeded  to  add  the  ability  of  sending  the  radar  detections  to  other  members  of  the  federation. 
The  final  phases  of  implementing  HLA  modifications  to  SAFIRE  involved  making  parameter 
changes  in  the  radar  based  on  received  HLA  communication  requests  and  inserting  the  latest 
flight  dynamics  into  SAFIRE  for  simulation.  The  final  configuration  of  the  RTI  communications 
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between  the  federates  in  the  distributed  radar  simulation  is  illustrated  in  Figure  6.  The 
distributed  operation  of  SAFIRE  was  thoroughly  tested  before  integration  with  the  ACD  was 
attempted. 

Implementation  was  aided  by  the  development  of  two  test  programs;  a  Test  Stub  and  an 
Observer.  The  Test  Stub  program  generates  the  necessary  interactions  to  test  the  behaviour  of  D- 
SAFIRE  and  replaces  the  ACD  components  of  the  simulation  for  testing.  The  Test  Stub  sends 
RTI  communications  that  have  been  saved  in  a  file.  The  Observer  program  was  developed  to 
observe  all  the  communication  in  the  federation  and  verify  what  was  being  communicated.  The 
two  test  programs  used  the  same  architecture  as  D-SAFIRE  so  very  little  additional  time  was 
needed  to  implement  these  programs. 

During  testing  of  the  modifications  to  SAFIRE,  it  was  discovered  that  the  added  time  to  maintain 
the  GUI  caused  the  program  not  to  operate  in  realtime.  The  GUI  was  made  optional  as  a  compile 
time  constant,  as  a  compromise  to  the  existing  SAFIRE  program,  in  order  to  achieve  real  time 
operation.  However,  a  separate  version  of  D-SAFIRE  with  the  GUI  was  created  in  order  to 
facilitate  debugging  and  demonstrations.  With  some  additional  optimizations  of  the  code  that 
interfaced  with  the  RTI,  D-SAFIRE  did  operate  in  real  time  for  the  simulation. 


D-SAFIRE 


Graphical  User  Interface 
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Figure  5:  D-Safire  software  components. 
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2.3  HLA  Integration  with  ACD 

The  integration  of  the  ACD  with  the  radar  model  via  the  HLA  framework,  required  collecting  all 
of  the  relevant  information  from  the  different  programs.  Both  the  FLSIM  and  STAGE  programs 
were  running  on  the  Onyx  1  workstation.  These  two  programs  generated  the  ownship  and  target 
aircraft  flight  dynamics.  The  direct  pilot  interaction  with  the  cockpit  was  controlled  by  the 
VAPS  software  on  the  Onyx  2  workstation.  Since  the  toolset  being  used  for  this  simulation  did 
not  include  existing  HLA  components,  these  were  added  manually. 

The  earlier  design  and  test  work  carried  out  by  VPI  on  the  D-SAFIRE  components  combined 
with  the  DMSO  HLA  RTI  1.3NG  tools  provided  all  of  the  necessary  programming  interfaces  for 
integration  with  the  HLA.  The  routines  from  the  test  stub  program  in  Figure  5  were  used  as  the 
RTI  communications  calls.  Accessing  the  required  parameters  required  additional  effort. 

The  methodology  for  acquiring  all  of  the  data  fields  required  for  the  radar  model,  and  for 
supplying  those  values  to  the  ACD  simulation  relied  upon  specially  coded  Simulation  to  RTI 
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Interface  Modules  (SRIMs).  CMC  programmed  the  HLA  interface  to  access  the  SRIMs  for  each 
of  FLSIM,  STAGE,  and  the  VAPS  cockpit  displays  and  controls..  The  overall  design  of  the  ACD 
can  be  seen  in  Figure  7. 

The  ACD  SRIM  ran  on  the  same  machine  as  STAGE  and  FLSIM.  Communication  between  the 
HLA  module  and  STAGE  and  FLSIM  was  done  using  shared  memory  to  access  the  target  and 
ownship  data  respectively.  The  radar  properties  wcic  taken  from  the  cockpit  display  simulation 
on  the  Onyx  2  workstation.  A  UDP  connection  was  established  by  the  SRIM  between  Onyx  1 
and  Onyx  2  in  order  to  get  the  current  radar  parameters  and  forward  them  to  SAFIRE  using  HLA 
communication  mechanisms.  The  UDP  connection  was  also  used  to  deliver  the  radar  status 
reports  received  from  SAFIRE  to  the  SRIM  process  running  on  Onyx  2.  The  radar  detections 
received  in  the  status  reports  were  transferred  to  the  cockpit  display  simulation. 

Since  some  of  the  displays  were  attempting  to  present  merged  radar  and  other  sensor 
information,  not  all  of  the  information  about  the  radar  detections  requested  by  the  CMC 
programmers  could  be  supplied  by  D-SAFIRE.  The  ACD  SRIM  took  the  necessary  information 
from  STAGE  and  used  that  to  display  the  detection.  In  addition,  some  information  required  by  D- 
SAFIRE  was  not  generated  by  STAGE.  The  missing  information  was  the  line  of  sight  velocity 
and  acceleration  for  the  target.  These  values  were  calculated  by  the  ACD  SRIM  based  on  other 
information  taken  from  STAGE. 

For  the  execution  of  the  federation,  the  RTIexccutivc  and  fedex  processes  also  ran  on  the  Onyx  1 
machine.  These  processes  could  have  been  run  on  any  computer  in  the  network  but  were  run  on 
the  Onyx  1  woricstation  to  reduce  network  communication  requirements. 
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Figure  7:  Air  Crewstation  Demonstrator  software  and  hardware  architecture 
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3.  Summary  of  Implementation  and  Utilization 

This  section  summarizes  some  of  the  difficulties  in  integrating  the  ACD  and  D-SAFIRE  as  well 
as  how  the  simulation  was  operated.  The  first  section  discusses  some  of  the  problems 
encountered  and  solutions  to  those  problems.  The  second  section  illustrates  how  the  distributed 
simulation  was  started,  run  and  shut  down. 

3.1  Capabilities  and  Limitations 

In  this  section  some  of  the  difficulties  that  occurred  during  integration  of  the  ACD  with  D- 
SAFIRE  arc  discussed.  Some  modifications  of  the  FOM  occurred  late  in  the  integration  phase  of 
the  project.  These  modifications  arc  discussed  later  in  this  section.  It  was  not  possible  to  achieve 
the  desired  update  rate  for  the  simulation.  This  section  begins  with  a  discussion  of  the  difficulty 
achieving  the  desired  update  rate. 

An  update  rate  of  30  Hz  for  the  scenario  state  was  set  as  a  goal  for  the  simulation.  During 
integration  of  D-SAFIRE  with  the  ACD,  a  rate  of  approximately  3Hz  was  all  that  could  be 
achieved.  A  faster  update  rate  caused  the  scenario  information  to  be  delivered  to  D-SAFIRE  in 
bursts.  This  problem  with  the  delivery  of  the  simulation  updates  was  never  satisfactorily 
resolved. 

One  attempt  to  resolve  the  update  rate  problem  consisted  of  the  use  of  “best-effort”  (UDP) 
connections  instead  of  “reliable”  (TCP)  connections.  It  was  thought  that  since  the  UDP 
connection  requires  less  processing  it  might  be  possible  to  achieve  a  higher  update  rate.  The  type 
of  connection  used  is  specified  in  the  federation  execution  details  file  “D-SAFIRE.fcd”.  The 
“best-effort”  connection  resulted  in  a  complete  loss  of  communication  between  D-SAFIRE  and 
the  ACD.  The  reason  for  this  complete  loss  was  unknown. 

In  a  second  attempt  to  resolve  the  update  problem,  some  of  the  communication  parameters  in  the 
“RTI.rid”  file  were  optimized.  It  was  also  hoped  to  optimize  the  data  transfer  times  while  trying 
to  resolve  the  update  rate  problem.  The  parameters  of  interest  specified  the  maximum  size  and 
wait  time  before  sending  data.  The  maximum  time  before  sending  data  was  set  at  0.03s  and  the 
maximum  number  of  bytes  before  sending  was  set  at  256bytcs.  No  optimisation  of  these 
parameters  resolved  the  update  rate  problem.  The  final  “RTI.rid”  file  contents  can  be  seen  in 
Annex  C. 

The  bandwidth  used  on  the  ISDN  line  at  the  2Hz  update  rate  was  approximately  60%  of  the 
128Kbps  capacity.  This  greatly  exceeds  the  expected  bandwidth  required  based  on  the  amount  of 
data  being  sent.  This,  combined  with  the  lack  of  communication  with  UDP  connection,  indicates 
that  either  a  large  number  of  packets  were  being  lost  or  corrupted  between  the  CMC  and  DREO 
sites  or  there  was  other,  unexpected  traffic  between  the  two  sites. 
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In  order  to  compensate  for  the  poor  update  rate,  extrapolation  methods  were  added  to  D-S AFIRE. 
These  methods  update  the  aircraft  and  target  flight  dynamics  based  on  the  last  received  update. 
The  extrapolation  was  applied  after  each  Coherent  Processing  Interval  (CPI)  in  D-SAFIRE.  A 
CPI  in  D-SAFIRE  simulates  one  processing  cycle  of  the  radar  and  takes  between  6-8ms.  The 
modular  design  of  the  SAFIRE  model  permitted  the  extrapolation  code  to  be  added  with  little 
impact  on  the  existing  code.  Since  the  simulation  did  not  include  detailed  tracking  modes,  such 
as  STT,  there  were  no  requirements  to  smooth  the  parameter  estimates  between  CPIs.  If  STT 
modes  were  to  be  used  in  this  manner,  further  adaptation  would  be  required  to  ensure  that 
tracking  filters  performed  correctly. 

In  the  original  specification  for  the  simulation,  D-SAFIRE  was  to  simulate  only  the  Range- 
While-Scan  (RWS)  mode  of  the  APG-65.  The  Track- While-Scan  (TWS)  mode  was  added  during 
implementation.  The  addition  of  the  TWS  mode  required  some  modifications  to  the  Radar  Status 
Report  in  the  FOM.  The  TWS  mode  required  an  additional  field  describing  the  track  quality  in 
the  status  report  and  a  redefinition  of  the  types  of  status  reports  possible.  TWS  mode  was 
successfully  added  to  the  capability  of  D-SAFIRE  with  some  limitations.  CMC  requested  that 
the  target  aspect  be  supplied  for  all  targets.  D-SAFIRE  was  programmed  based  on  older  radar 
specifications  and  could  generate  the  target  aspect  only  for  the  Launch  and  Steer  (L&S)  target 
while  in  TWS  mode.  Thus  it  was  not  possible  to  send  this  information  for  all  detections.  As  a 
work  around  for  this  problem  CMC  took  the  target  aspect  from  STAGE.  However,  in  order  to 
extract  the  information  from  STAGE  it  was  necessary  to  know  which  source  target  generated  the 
detection.  Since  the  radar  simulation  does  not  apply  any  target  association  between  the 
information  used  to  generate  the  target  and  the  data  used  to  generate  the  detections,  this 
information  is  not  available  from  the  radar  model.  In  order  to  ensure  an  exact  match  between  the 
detection  and  the  target  it  was  decided  to  limit  the  number  of  targets  sent  to  the  radar  model  to 
one. 

The  use  of  only  one  target  also  solved  an  additional  problem  caused  by  the  slow  update  rate.  The 
target  updates  did  not  occur  at  a  sufficient  rate  to  permit  constant  updating  of  the  radar  display. 
Thus,  the  scenarios  were  set  up  so  that  all  radar  target  information  was  extracted  from  the 
SRIMs.  During  the  simulation  the  current  flight  data  for  the  targets  and  the  ACD  were  taken 
from  the  FLSIM  and  STAGE  and  sent  to  D-SAFIRE.  D-SAFIRE  would  receive  the  current 
target,  aircraft  and  radar  control  information  from  the  ACD.  The  radar  return  was  calculated  from 
this  information  and  the  radar  model  then  simulated  the  behaviour  of  the  APG-65  radar.  If  a 
target  was  detected  D-SAFIRE  would  generate  a  Radar  Status  Report  and  send  it  back  to  the 
ACD.  When  D-SAFIRE  first  detected  the  target  a  flag  was  set  to  activate  the  ‘SAFIRE’  target. 
The  flag  allowed  the  target  data  to  be  taken  from  STAGE  and  used  to  update  the  target 
information  on  the  radar  display.  A  timer  was  used  to  remove  the  target  from  the  display  if  no 
update  was  received  from  D-SAFIRE  within  8  seconds. 

There  were  many  user  interface  and  display  issues  that  could  not  be  addressed  in  Ihe  limited  time 
permitted  for  implementation  of  the  prototype  cockpit  displays.  The  ACD  implementation  did 
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not  include  the  ability  for  the  pilot  to  modify  the  radar  antenna  elevation,  nor  did  it  display  the 
correct  antenna  elevation.  Target  aging  was  another  function  that  was  not  implemented  as 
defined  for  the  CF-18.  The  ACD  was  designed  to  demonstrate  the  capabilities  of  the  upgraded 
radar,  but  the  radar  model  was  based  on  the  existing  radar.  Thus  certain  functionalities,  such  as 
the  fusion  of  data  link  targets  and  radar  targets  were  not  implemented  in  the  radar  model,  nor 
were  they  implemented  in  the  ACD  in  a  manner  similar  to  the  actual  system. 

3.2  Experiment  Utilization 

Once  D-SAFIRE  and  the  ACD  were  integrated  the  distributed  simulation  ran  smoothly.  The 
simulation  protocol  required  that  the  ‘SAFIRE’  target  be  defined  before  the  simulation  was  run. 
The  initialization  of  HLA  communications  components  was  highly  order  dependent,  and  the 
simulation  programs  were  required  to  started  in  a  specific  order.  No  human  intervention,  except 
by  the  ownship  pilot,  was  required  to  keep  the  distributed  simulation  operating  for  a  given 
scenario.  At  the  end  of  the  experiments,  all  of  the  processes  were  tenninated  manually. 

As  mentioned  in  the  previous  section,  one  target  in  the  simulation  was  selected  beforehand  to  be 
used  in  the  distributed  simulation.  During  typical  operation,  the  chosen  target’s  flight  dynamics, 
along  with  Electromagnetic  (EM)  characteristics  and  Electronic  Counter  Measures  (EMC) 
configuration  for  that  target,  were  sent  to  D-SAFIRE.  The  flight  dynamics  (i.e.  position,  velocity 
and  acceleration)  and  “Weapons  Configuration”  of  the  ACD  were  also  sent  to  D-SAFIRE.  In 
addition  to  the  flight  dynamic  of  the  ACD  and  chosen  target  aircraft,  the  parameters  controlling 
the  radar,  such  as  radar  mode,  azimuth  and  elevation  centre  and  azimuth  scan  range  were  sent  to 
D-SAFIRE.  All  display  changes,  and  valid  mode  requests  were  detected  by  the  D-SAFIRE  radar 
model  and  reflected  in  the  radar  status  reports.  Due  to  the  low  update  rate,  and  the  requirement 
to  simulate  only  one  target,  is  was  possible  to  run  D-SAFIRE  with  the  GUI  active.  Thus,  while 
the  radar  model  operators  were  unable  to  view  the  actual  simulation  in  the  ACD,  they  were  able 
to  observe  the  ownship  and  target  aircraft  manoeuvres  via  the  local  radar  display. 

Initial  set  up  of  the  distributed  simulation  required  FLSIM  and  STAGE  programs  to  be  started 
first.  The  RTIexecutive  program  was  then  started  on  the  Onyx  1  workstation.  The  parent  D- 
SAFIRE  was  then  started  and  contacted  the  RTIexecutive  running  at  the  CMC  facility  to  create 
join  the  simulation  federation.  The  HLA  integration  module  for  the  ACD  was  then  started.  The 
HLA  integration  module  requested  the  creation  of  a  radar  object  and  immediately  begin  sending 
updates  to  D-SAFIRE.  The  updates  would  each  contain  the  same  data  until  the  actual  simulation 
began. 

The  ACD  was  demonstrated  using  the  D-SAFIRE  radar  model  in  26  of  the  32  mission 
simulations.  During  each  of  these,  the  radar  model  generated  the  detections  for  the  designated 
‘SAFIRE’  target  consistently.  The  limitations  of  working  with  the  incomplete  sensor  model  and 
interfaces  were  avoided  through  the  careful  design  of  the  scenarios  by  the  CMC  experimenters. 
Occasionally  targets  were  missed  due  to  improper  antenna  elevation  settings  or  the  radar  displays 
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presented  overly  accurate  data  due  to  their  reliance  on  the  information  from  the  STAGE  program 
rather  than  on  the  radar  outputs.  This  was  especially  true  for  the  aspect  vector  information  which 
was  noted  to  be  extremely  stable  in  the  ACD  simulation. 
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4.  Conclusions  and  Recommendations 


Overall,  the  distributed  simulation  succeeded  in  providing  a  means  of  demonstrating  radar 
performance  issues  by  integrating  a  validated  radar  model  with  the  cockpit  simulation.  Given  the 
limited  scope  of  the  original  tasking  and  the  current  limitations  of  processing  and 
communications  hardware,  the  system  performed  well,  with  many  positive  comments  from  the 
operators.  The  following  sections  summarize  some  of  the  lessons  learned  during  the 
implementation  of  the  distributed  simulation  and  present  some  recommendations  for  future  work. 

4.1  Lessons  Learned 

One  of  the  first  lessons  learned  was  differences  between  the  human  factors  and  sensor  model 
simulation  communities.  The  emphasis  of  the  HFE  simulation  community,  those  implementing 
the  ACD,  was  on  the  details  in  user  interface.  The  performance  of  the  sensor  models  in  terms  of 
‘correctness’  were  less  important  and  they  would  be  satisfied  with  results  that  looked  correct. 

The  sensor  model  simulation  group  at  DREO  was  more  concerned  about  simulating  some  of  the 
limitations  of  the  sensor  to  provide  more  realistic  sensor  performance.  This  had  a  larger  impact 
on  this  simulation  due  to  the  different  time  lines  between  the  two  groups.  The  radar  model  and 
initial  FOM  were  designed  by  the  sensor  model  group  with  input  from  the  ACD  implementation 
team.  However,  the  implementation  of  the  radar  model  specific  portions  of  the  ACD  were 
carried  out  late  in  the  project  and  it  was  at  this  time  that  the  impact  of  the  different  viewpoints 
became  apparent. 

One  of  the  primary  goals  of  the  sensor  model  team  was  to  determine  the  effort  required  to 
convert  the  stand  alone  legacy  radar  simulation  into  a  part  of  a  larger  distributed  simulation. 
Despite  a  lack  of  previous  experience  with  HLA  by  almost  all  of  the  participants,  the 
infrastructure  provided  by  the  HLA  was  readily  adapted  to  the  existing  simulations.  The  original 
design  of  the  SAFIRE  radar  model  was  very  modular,  and  the  separation  between  the  GUI  and 
the  SSS  permitted  the  insertion  of  the  HLA  components  relatively  easily.  The  implementation  of 
the  distributed  radar  simulation  demonstrated  that  the  sensor  models,  if  designed  in  a  modular 
fashion,  are  readily  adapted  to  a  distributed  simulation  environment.  Detailed  knowledge  of 
HLA  is  most  important  at  the  beginning  of  the  project  in  determining  optimal  design  decisions 
and  at  the  end  of  the  project  in  achieving  the  best  performance  of  the  simulation. 

Communications  expertise  for  the  communication  protocol  being  used  is  also  important  when 
attempting  to  achieve  realtime  performance.  One  of  the  problems  with  the  simulation  was  the 
low  update  rate  of  only  2Hz.  This  was  caused  by  the  poor  network  performance  over  the  ISDN 
backbone,  data  being  sent  in  uneven  bursts,  possible  excessive  network  traffic,  and  the  complete 
loss  of  the  UDP  packets  when  attempting  to  use  the  ‘best-effort’  mode  of  the  HLA  federation. 
While  HLA  removes  the  necessity  of  all  of  the  programmers  from  understanding  the  underlying 
communications  protocols,  it  is  necessary  to  have  someone  involved  who  understands  the  effects 
of  the  various  choices.  Later  testing[8]  indicated  that  with  a  single  target,  and  the  GUI  disabled, 
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D-SAFIRE  is  capable  of  maintaining  a  an  update  rate  of  20Hz  over  a  standard  lOBase  T  Ethernet 
connection.  For  4  targets  this  drops  to  8Flz,  but  still  exceeds  the  2Hz  used  in  the  distributed 
simulation. 

4.2  Recommendations 

The  results  of  this  simulation  effort  have  demonstrated  that  modular  sensor  models  can  be 
integrated  into  distributed  simulations  with  little  modification  of  the  current  code.  However, 
realtime  performance  issues  currently  limit  the  use  of  detailed  models  such  as  SAFIRE  in  a 
human-in-the-loop  simulation.  These  models  often  have  to  run  in  limited  scenarios,  with  certain 
capabilities  removed.  Thus  for  these  types  of  simulations,  it  is  recommended  that  simpler 
representative  models  be  used.  An  example  of  this  for  the  CF- 1 8  is  the  radar  model  currently  in 
use  with  the  CF-18  ACES  project  [9]. 

One  area  where  this  distributed  simulation  capability  would  be  very  useful  with  detailed 
simulations  are  complete  system  simulations.  In  addition  to  the  SAFIRE  radar  model,  there 
currently  exists  several  sensor  model  simulations  for  the  CF-18  aircraft  such  as  electronic  support 
measure  (ESM)  sensors.  Combining  these  with  a  flight  simulator  and  scenario  management  tool 
would  enable  the  entire  aircraft  sensor  environment  to  be  simulated  in  a  co-ordinated  fashion. 
This  first  stage  would  permit  one  aircraft  using  ESM  sensors  to  detect  the  radar  of  the  a  second 
aircraft,  which  would  in  turn,  send  a  selected  jamming  mode  back  to  the  SAFIRE  radar  model. 
This  would  allow  the  verification  of  various  jamming  programs  against  multi-mode  radars  as 
opposed  to  verifying  only  specific  techniques  against  a  single  mode.  The  integration  of  missile 
flight  and  missile  seeker  models  would  also  permit  the  verification  of  jamming  programs  on 
missile  effectiveness  in  more  realistic  circumstances  than  are  currently  possible.  These  types  of 
simulation  do  not  require  realtime  performance.  It  is  highly  recommended  that  future 
simulations  proceed  along  these  lines  to  provide  significantly  improved  system  performance 
estimates  for  future  sensor  systems. 
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Annex  A  Network  Configuration  for  SAFIRE  HLA 


The  following  is  a  description  of  the  configuration  parameters  used  for  the  ACD  HLA  ISDN 
network  connections.  Note  that  arbitrary  addresses  are  used  since  the  connection  is  assumed  to 
be  point  to  point  over  the  switches  and  that  any  address  will  not  cause  tiie  system  to  generate 
requests  outside  of  the  dedicated  connection  configured  in  this  way. 

DREO  ISDN  Router  Configuration 


Switch  type 

NI-1 

Channel  Usage 

Switch/Switch 

Contact  number 

as  provided  by  telecommunications  provider 

SPID  numbers 

as  provided  by  telecommunications  provider 

Local  name 

dreo 

Local  router  IP  address 

131.136.36.1/24 

Remote  name 

baesystems 

Remote  router  IP  address 

192.75.86.170/24 

Remote  dial-up  number 

as  provided  by  telecommunications  provider 

Route 

IP 

Send  auth/Recv  auth 

PAP 

Network  IP  Addresses  for  Federation 


DREO  observer  (dreo  nt/dreo  hla  node) 

131.136.36.71 

DREO  Radar  Model  /  Schroeder 

131.136.36.74 

BAE  RTI 

192.71.86.160 
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Configuration  of DREO  Sun  Workstation  (  SAFIRE  platfonn  ) 

1)  Modify  /etc/nsswitch.config 

a.  This  file  is  modified  to  ensure  that  files  arc  check  before  [NOT  FOUND  = 
return].  Otherwise,  /etc/hosts  and  /ctc/passwd  arc  not  checked. 

2)  /etc/hosts:  add  above  ip  names  and  addresses 

3)  /etc/passwd:  Copy  hla  users  to  passwd  file.  Copy  passwords  to  /etc/shadow. 

4)  /etc/vfstab:  Ensure  no  remote  file  systems  arc  mounted  on  Schrocder.  Also 
unmount  all  volumes  from  other  locations.  I.e.  unmount  /fluorine  on  Linus. 

5)  /etc/auto_home:  For  users  who  may  log  on  to  Schrocder,  ensure  that  their 
accounts  arc  created  locally  ( added  /fluorinc/homc ). 

6)  /etc/defaultdomain:  A  copy  of  this  file  is  stored  in  dcfaultdomain.drco.  This  must 
be  deleted  to  boot  on  the  restricted  ISDN  network,  and  copied  back  from 
dcfaultdomain.drco  to  reboot  on  the  DREO  LAN. 
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Annex  B  D-SAFIRE  Federation  Execution  Details 


(FED 

(Federation  CF- 1 8_APG  -65_simulation) 

(FEDversion  vl.3) 

(spaces 

) 

(objects 

(class  ObjectRoot 

(attribute  privilegeToDelete  reliable  timestamp) 
(class  RTIprivate) 

(class  Aircraft 

(attribute  TSPI  best_effort  receive) 

(attribute  WeaponConfiguration  best  effort  receive) 

) 

(class  Radar 

(attribute  Radar_Parameters  best_effort  receive) 
(attribute  Radar_Status  best_effort  receive) 

(attribute  Target_Processing_List  best_effort  receive) 

) 

(class  Manager 
(class  Federation 

(attribute  FederationName  reliable  receive) 

(attribute  FederatesInFederation  reliable  receive) 
(attribute  RTIversion  reliable  receive) 

(attribute  FEDid  reliable  receive) 

(attribute  LastSaveName  reliable  receive) 

(attribute  LastSaveTime  reliable  receive) 

(attribute  NextSaveName  reliable  receive) 

(attribute  NextSaveTime  reliable  receive) 

) 

(class  Federate 

(attribute  FederateHandle  reliable  receive) 

(attribute  FederateType  reliable  receive) 

(attribute  FederateHost  reliable  receive) 

(attribute  RTIversion  reliable  receive) 

(attribute  FEDid  reliable  receive) 

(attribute  TimeConstrained  reliable  receive) 

(attribute  Time  Regulating  reliable  receive) 

(attribute  AsynchronousDelivery  reliable  receive) 
(attribute  FederateState  reliable  receive) 

(attribute  TimeManagerState  reliable  receive) 
(attribute  FederateTime  reliable  receive) 

(attribute  Lookahead  reliable  receive) 

(attribute  LBTS  reliable  receive) 

(attribute  MinNextEventTime  reliable  receive) 
(attribute  ROlength  reliable  receive) 

(attribute  TSOlength  reliable  receive) 

(attribute  ReflectionsReceived  reliable  receive) 
(attribute  UpdatesSent  reliable  receive) 
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(attribute  InteractionsReceived  reliable  receive) 
(attribute  InteractionsSent  reliable  receive) 

(attribute  ObjectsOwned  reliable  receive) 

(attribute  ObjectsUpdated  reliable  receive) 

(attribute  ObjectsReflected  reliable  receive) 

) 

) 

) 

) 

(interactions 

(class  InteractionRoot  reliable  timestamp 
(class  RTIprivate  reliable  timestamp) 

(class  Terminate_Simulation  reliable  receive 
(parameter  SAFIRE_terminate) 

) 

(class  Create  Radar  Object  reliable  receive 
(parameter  SAFIREexecute) 

) 

(class  Destroy_RadarmObject  reliable  receive 
(parameter  SAFIRE  exit) 

) 

(class  Radar_Pause_Request  reliable  receive 
(parameter  SAFIRE  pause) 

) 

(class  Radar_Continue_Request  reliable  receive 
(parameter  SAFIRE_continue) 

) 

(class  Update_Aircraft  best_effort  receive 
(parameter  Aircraft) 

) 

(class  Update_Target_Processing_List  best_effort  receive 
(parameter  trg  prl) 

) 

(class  Radar_Parameters  best_effort  receive 
(parameter  rdr_prm) 

) 

(class  Radar_Status_Report  best_effort  receive 
(parameter  rdr_sts) 

) 

(class  Manager  reliable  receive 

(class  Federate  reliable  receive 
(parameter  Federate) 
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(class  Request  reliable  receive 
(class  RequestPublications  reliable  receive 
) 

(class  RequestSubscriptions  reliable  receive 

) 

(class  RequestObjectsOwned  reliable  receive 

) 

(class  RequestObjectsUpdated  reliable  receive 

) 

(class  RequestObjectsReflected  reliable  receive 

) 

(class  RequestUpdatesSent  reliable  receive 

) 

(class  RequestlnteractionsSent  reliable  receive 

) 

(class  RequestReflectionsReceived  reliable  receive 

) 

(class  RequestlnteractionsReceived  reliable  receive 

) 

(class  RequestObjectlnformation  reliable  receive 
(parameter  Objectlnstance) 

) 

) 

(class  Report  reliable  receive 
(class  ReportObjectPublication  reliable  receive 
(parameter  NumberOfClasses) 

(parameter  ObjectClass) 

(parameter  AttributeList) 

) 

(class  ReportObjectSubscription  reliable  receive 
(parameter  NumberOfClasses) 

(parameter  ObjectClass) 

(parameter  Active) 

(parameter  AttributeList) 

) 

(class  ReportlnteractionPublication  reliable  receive 
(parameter  InteractionC lassList) 

) 
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(class  ReportlnteractionSubscription  reliable  receive 
(parameter  InteractionC lassList) 

) 

(class  ReportObjectsOwned  reliable  receive 
(parameter  ObjectCounts) 

) 

(class  ReportObjectsUpdated  reliable  receive 
(parameter  ObjectCounts) 

) 

(class  ReportObjectsReflected  reliable  receive 
(parameter  ObjectCounts) 

) 

(class  ReportUpdatesSent  reliable  receive 
(parameter  TransportationType) 

(parameter  UpdateCounts) 

) 

(class  ReportReflectionsReceived  reliable  receive 
(parameter  TransportationType) 

(parameter  ReflectCounts) 

) 

(class  ReportlnteractionsSent  reliable  receive 
(parameter  TransportationType) 

(parameter  InteractionCounts) 

) 

(class  ReportlnteractionsReceived  reliable  receive 
(parameter  TransportationType) 

(parameter  InteractionCounts) 

) 

(class  ReportObjectlnformation  reliable  receive 
(parameter  Objectlnstance) 

(parameter  Owned  AttributeList) 

(parameter  RegisteredClass) 

(parameter  KnownClass) 

) 

(class  Alert  reliable  receive 
(parameter  AlertSeverity) 

(parameter  AlertDescription) 

(parameter  AlertID) 

) 

(class  ReportServicelnvocation  reliable  receive 
(parameter  Service) 


(parameter  Initiator) 

(parameter  Successlndicator) 
(parameter  SuppliedArgumentl) 
(parameter  SuppliedArgument2) 
(parameter  SuppliedArgument3) 
(parameter  SuppliedArgument4) 
(parameter  SuppliedArgument5) 
(parameter  Returned  Argument) 
(parameter  ExceptionDescription) 
(parameter  ExceptionID) 

) 

) 


(class  Adjust  reliable  receive 

(class  SetTiming  reliable  receive 
(parameter  ReportPeriod) 

) 

(class  Modify AttributeState  reliable  receive 
(parameter  Objectlnstance) 

(parameter  Attribute) 

(parameter  AttributeState) 

) 

(class  SetServiceReporting  reliable  receive 
(parameter  ReportingState) 

) 

(class  SetExceptionLogging  reliable  receive 
(parameter  LoggingState) 

) 

) 


(class  Service  reliable  receive 
(class  ResignFederationExecution  reliable  receive 
(parameter  ResignAction) 

) 

(class  SynchronizationPointAchieved  reliable  receive 
(parameter  Label) 

) 

(class  FederateSaveBegun  reliable  receive 

) 


(class  FederateSaveComplete  reliable  receive 
(parameter  Successlndicator) 

) 
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(class  FederateRestoreComplete  reliable  receive 
(parameter  Successlndicator) 

) 

(class  PublishObjectClass  reliable  receive 
(parameter  ObjectClass) 

(parameter  AttributeList) 

) 

(class  UnpublishObjectClass  reliable  receive 
(parameter  ObjectClass) 

) 

(class  PublishlnteractionClass  reliable  receive 
(parameter  InteractionClass) 

) 

(class  UnpublishlnteractionClass  reliable  receive 
(parameter  InteractionClass) 

) 

(class  SubscribeObjectClassAttributes  reliable  receive 
(parameter  ObjectClass) 

(parameter  AttributeList) 

(parameter  Active) 

) 

(class  UnsubscribeObjectClass  reliable  receive 
(parameter  ObjectClass) 

) 

(class  SubscribelnteractionClass  reliable  receive 
(parameter  InteractionClass) 

(parameter  Active) 

) 

(class  UnsubscribelnteractionClass  reliable  receive 
(parameter  InteractionClass) 

) 

(class  DeleteObjectlnstance  reliable  receive 
(parameter  Objectlnstance) 

(parameter  Tag) 

(parameter  FederationTime) 

) 

(class  LocalDeleteObjectlnstance  reliable  receive 
(parameter  Objectlnstance) 

) 

(class  ChangeAttributeTransportationType  reliable  receive 
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(parameter  Objectlnstance) 

(parameter  AttributeList) 

(parameter  TransportationType) 

) 

(class  ChangeAttributeOrderType  reliable  receive 
(parameter  Objectlnstance) 

(parameter  AttributeList) 

(parameter  OrderingType) 

) 

(class  ChangelnteractionTransportationType  reliable  receive 
(parameter  InteractionClass) 

(parameter  TransportationType) 

) 

(class  ChangelnteractionOrderType  reliable  receive 
(parameter  InteractionClass) 

(parameter  OrderingType) 

) 

(class  UnconditionalAttributeOwnershipDivestiture  reliable  i 
(parameter  Objectlnstance) 

(parameter  AttributeList) 

) 

(class  EnableTimeRegulation  reliable  receive 
(parameter  FederationTime) 

(parameter  Lookahead) 

) 

(class  DisableTimeRegulation  reliable  receive 

) 

(class  EnableTimeConstrained  reliable  receive 

) 

(class  DisableTimeConstrained  reliable  receive 

) 

(class  EnableAsynchronousDelivery  reliable  receive 

) 

(class  DisableAsynchronousDelivery  reliable  receive 

) 


(class  ModifyLookahead  reliable  receive 
(parameter  Lookahead) 

) 

(class  TimeAdvanceRequest  reliable  receive 
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(parameter  FederationTime) 

) 

(class  TimeAdvanceRequestAvailable  reliable  receive 
(parameter  FederationTime) 

) 

(class  NextEventRequest  reliable  receive 
(parameter  FederationTime) 

) 

(class  NextEventRequestAvailable  reliable  receive 
(parameter  FederationTime) 

) 

(class  FlushQueueRequest  reliable  receive 
(parameter  FederationTime) 

) 


) 

) 

) 

) 

> 

) 


t 


30 


DREOTM  2001-151 


Annex  C  RTI.rid  file 


(RTI 

(ProcessSection 

(RtiExecutive 

(RtiExecutiveEndpoint  192.75.86.53:20065) 
;;(RtiExecutiveEndpoint  131.136.36.71 :20065) 


;;  remember  that  rtiexec  -multicastDiscoveryEndpoint  flag  must 
;;  match  this,  or  you'll  get  NameService  errors 
“(RtiExecutiveMulticastDiscoveryEndpoint  224.9.9.2:12345) 

; ;  (NumberOfAttemptsT  oFindRtiExecutive  1 0) 

) 

) 

) 

(FederationSection 
; ;  (F  ederationExecutive 
;;(FilenameToRedirectStdout"log.txt") 
;;(FilenameToRedirectStderr  "log.txt") 

;;) 

(Networking 

(BundlingOptions 

(UDP 

(MaxTimeBeforeSendlnSeconds  0.0001) 

(MaxBytesBeforeSend  256) 

) 

(TCP 

(MaxTimeBeforeSendlnSeconds  0.03) 

(MaxBytesBeforeSend  256) 

) 

) 

(MulticastOptions 

;;  having  different  federations  on  network  use  different  ranges  of 
;;  multicast  addresses  will  help  performance 
(BaseAddress  224. 100.0.0) 

;;(MaxAddress  239.255.255.255) 

) 

) 

(Advisories 

;;  (Relevance  Advisory  A  ttributelnstance  Heartbe  atlnSeconds  Off) 

;  ;(Relevance  Advisory  A  ttributelnstance  T  imeo  utlnSeco  nds  Off) 
;;(Relevance  AdvisorylnteractionClassFleartb  eatlnSeconds  Off) 
“(Relevance  AdvisorylnteractionC  lassTimeo  utlnSeco  nds  O ff) 
“(Relevance  Advisory O bjectClas sHeartbe atlnSeco nds  Off) 
;;(RelevanceAdvisoryObjectClassTimeo  utlnSeco  nds  Off) 

) 
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(FederateSection 

(EventRetractionHandleCacheOptions 

;;  the  next  two  options  will  disable  event  retractions,  which  is 
;;  OK  since  helloworld  doesn't  use  them 
(MinimumCacheSizeBeforePerformingPurge  0) 

(NumberOfEventRetractionHandlesToCreateBeforeStartingNewPurgeCycle  0) 

) 

) 

) 

) 
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List  of  Symbols,  Abbreviations,  Acronyms  and  Initial  isms 


ACD 

Air  Crewstation  Demonstrator 

CMC 

Canadian  Marconi  Company 

D-SAFIRE 

Distributed-SAFIRE 

DDI 

Digital  Display  Indicator 

DMSO 

Defence  Modelling  and  Simulation  Office 

DREO 

Defence  Research  Establishment  Ottawa 

ECCM 

Electronic  Counter  Counter  Measure 

ECM 

Electronic  Counter  Measure 

EM 

ElectroMagnetic 

ESM 

Electronic  Support  Measure 

FLSIM 

Flight  Simulator 

FOM 

Federation  Object  Model 

HFE 

Human  Factors  Engineering 

HLA 

High  Level  Architecture 

HUD 

Head  Up  Display 

IEEE 

Institute  of  Electrical  and  Electronics  Engineers 

ISDN 

Integrated  Services  Digital  Network 

L&S 

Launch  and  Steer 

LAN 

Local  Area  Network 

OMDT 

Object  Model  Development  Tool 

RTI 

Run-Time  Infrastructure 

RWS 

Range  While  Scan 

SAFIRE 

Simulator  for  Advanced  Fighter  Radar  ECCM  Development 

SRIM 

Simulation  to  RTI  Interface  Module 

sss 

Scientific  Simulation  Software 

DREO  TM  2001-151 


STAGE 

Scenario  Toolkit  And  Generation  Environment 

STT 

Single  Target  Track 

TCP 

Transport  Control  Protocol 

TSPI 

Time  Space  Position  Indication 

TWS 

Track  While  Scan 

UDP 

User  Datagram  Protocol 

■4 
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